In many devices controlled by a microprocessor, there is a need for occasional modification or updates to the firmware. Historically, firmware was stored in a read-only-memory (ROM), and firmware modification was accomplished by replacing one or more ROMs. Replacement of ROMs typically required at least turning power off for a product and often required partial disassembly of a product. More recently, various types of programmable (write-once) or rewriteable nonvolatile memory is used, or sometimes battery powered volatile memory may be used. It is now common to send firmware updates electronically to a device and have the device modify or replace its own firmware. For example, modem firmware updates may be communicated over a telephone line and a modem may update its firmware without requiring opening of the modem's housing.
Typically, updating firmware in a running system may erase or change information that needs to remain unchanged until the next system reset. Typically, updating firmware in one device of a large system may require the entire system to be reset or rebooted. There is a need in some systems for the ability to update firmware within one device but to maintain integrity of some data and to continue operation without requiring an overall system reset or reboot. The following discussion provides two examples of devices where there is a need to preserve data during a firmware update. The first set of examples involves data being gathered and transmitted during initialization after a system reset. The second set of examples involves data that a device may need to communicate to other devices, or data that may affect external operation.
Many computer based systems undergo an automatic configuration process during an initialization process after power-on or during a reboot process. Typically, this requires all devices to run various initialization processes simultaneously. For example, for Intel compatible personal computers, one industry specification for automatically configuring I/O boards for the ISA bus is called the Plug and Play ISA Standards. For ISA Plug and Play, each compatible I/O card has a unique identifier that includes a vendor identifier and a serial number. Each compatible I/O card can read its own identifier. The host computer first places all the cards into a configuration mode. Then the host computer drives a line with a series of transitions indicating sequential bit positions within each identifier. As a result of interaction between the host computer and the I/O cards, one card is isolated and assigned a logical device number. The sequence is then repeated to isolate another card and so forth until all cards have been assigned a logical device number.
Another common interface standard is the Small Computer System Interface (SCSI). SCSI also requires a unique ID for each device. An industry group has proposed a set of specifications, called Plug and Play SCSI, which among other things provides automatic assignment of unique SCSI ID's. The particular protocol for assignment of unique ID's is called SCSI Configured AutoMagically (SCAM). Each SCAM compatible device has a default ID saved in a nonvolatile device memory. A SCAM master device first commands each of the other SCAM devices, one at a time, to go into an inactive state. Then, the master device uses a protocol similar to the protocol for ISA Plug and Play to isolate each device for assignment of a SCSI address.
There are other configuration protocols used by peripheral devices. If multiple devices are on one input/output port, devices may automatically configure themselves, at power-on, as primary and secondary devices. A device may need to record its own status (primary or secondary) and whether or not another device is sharing the same I/O cable.
In the second set of examples, some information that a device shares with other devices, or data that the device uses for various control functions, may change when firmware is updated. If the information is communicated to other devices only during power-on or reboot, then the information used by a device after a firmware update may be inconsistent or inappropriate. A system reboot may then be necessary. For example, consider again an identifier. Part of an identifier may indicate a firmware version or date code. Operating system software or other system devices may poll devices, at power-on or system reboot, and record a list of device identification numbers. Applications software may read such a list, and applications software may later refer to a specific device identifier. If a firmware update changes a device identifier, for example by changing a firmware version number, a system reboot may be required to update information gathered by the operating system or other system devices during system reboot. As an alternative example, consider a value, stored in firmware, that is written to a register of a control circuit during reset. If this value changes during a firmware update and the firmware is restarted, the control circuit output may change inappropriately.
From the above examples, there is a need for firmware updates that are transparent to a computer system or operator, so that a system reboot is not required.